DevOps CICD K8s DockerK8s是一個"集群(Cluster)"的架構，由一群節點(Node)集合而成，這些Node會將Application以容器的形式管理(要記住，在K8s中是不能直接對容器進行操作的，需要通過Pod。那Pod是甚麼呢?又為甚麼要這樣設計呢?放心，這些我們過兩天都會講到，就繼續看下去吧~)。
每個叢集當中會有一個Controller Plane 和數個Node，視你的需求而定(也可能有Multi-Controller Plane 的集群，類似Hot Standby的概念)。
Controller Plane在舊版的K8s稱為Master Node，而Node以前則叫做Slave/Worker Node或更早版本的Minion。兩者其實一樣，只是換了名詞而已
Controller Plane是整個K8s集群的大腦，是K8s運作的指揮中心。可以將Controller Plane看成一個特殊的Node，負責管理所有其他 Node。負責管理Pod的運作、生命週期、排程節點資源以及監控整個集群的狀態等等。是K8s中最重要的節點。通常Controller Plane會佔據一個獨立的Server(高可用佈署建議用三台Server)，因為它太重要了！Node是K8s的物件(resource-objects)實際運行的場所，可以對應到一台機器，像是筆電、虛擬機或是 AWS 上的一台 EC2 或 GCP 上的一台 Computer Engine (來源)。Node的工作是負責將Application以容器的形式運行在K8s集群中。接下來介紹一下這些Node各自包含哪些組件吧~
Controller Plane主要功能是Manage, Plan, Schedule, Monitor Node。一個 Controller Plane中包含四個組件：kube-apiserver、etcd、kube-scheduler、kube-controller-manager。
kube-apiserver是整個K8s集群最重要的組件，提供HTTP Rest介面的關鍵服務處理程序，是集群中各個節點的溝通橋樑，並管理整個 K8s 所需 API 的接口(Endpoint)。一旦kube-apiserver故障，整個集群就會無法操作，例如無法新增、刪除Pod等。另外，kube-apiserver也負責 K8s 中的請求的身份認證與授權
每個
Node之間的溝通必須要透過kube-apiserver，彼此之間是無法"直接"溝通的喔
用來存放 K8s Cluster 的資料作為備份，可以把他想像為整個集群的database，會記錄整個集群的狀態及資料。當 Controller Plane 故障時，可以透過 etcd 幫我們還原 Kubernetes 的狀態。
負責集群的資源調配，調度Pod運行在哪個Node上，是整個 Kubernetes 集群的調度員。
負責管理並運行 K8s controller 的組件，負責監視 Cluster 狀態的組件，是K8s中所有resource-objects的自動化控制中心。kube-controller-manager又可以細分為：
Controller-Manager
Node-Controller
Replication-Controller
詳細功能可以不用深度了解，有個概念就可以了~
kube-controller-manager的監視與更新也都需要透過訪問kube-apiserver達成
Node的工作只有一個，那就是Host Application as Containers，而Node又包含三個組件：kubelet、kube-proxy、Container Runtime。
對應api-server的接口，可以看成每個Node上的"實際執行者"或"操作者"，負責接收來自api-server的訊息，並做出相對應的動作，例如，負責Pod對應的容器的建立、啟動或停止等。
kube-proxy 是一個 network proxy，負責維護Node上的網路規則(iptables)，這些規則允許從群集內部或外部的與Pod進行通訊。
kube-proxy是
service的一部分概念。service會在之後幾天介紹
Node上運行容器的執行程式，K8s預設是Docker，但也支援其他Runtime Engine，例如rkt、CRI-O、containerd, kata container等
K8s本身只需要專注於kubelet以及CRI (Container Runtime Interface)標準的互動，第三方開發者則可以根據需求開發出各式各樣不同的產品，只要能夠滿足CRI標準，都可以作為K8s的Container Runtime Engine。因此不一定只能用Docker喔
這邊先提一下，在K8s中所有物件(resorce-object)都是用YAML File來描述。我們需要寫非常大量的YAML來創造物件，因此大家常常聽到K8s Engineering被稱為"YAML Engineering"就是這麼回事啦~如果對YAML格式不太熟悉的朋友可以參考這篇文章，裡面寫的滿詳細的。
YAML是一個可讀性高，用來表達資料序列化的格式。有點類似JSON檔。
而在K8s中的YAML檔，有四個欄位是必須的：apiVersion、kind、metadata、spec
apiVersion其實就是API的版本，因為k8s提供給每個物件的API版本都不同，需要跟著物件來更改需要的apiVersion。
kind就是我們這個YAML是要用來創造哪個物件。像是Pod、Service、Deployment等等。它們都有各自對應的apiVersion，像是：
| kind | apiVersion |
|---|---|
| Pod | v1 |
| Service | v1 |
| Deployment | apps/v1 |
| ReplicaSet | apps/v1 |
metadata是用來描述這個物件的資訊，像是它的名稱，lable等。
spec是這四個欄位中最重要的欄位，也是最複雜的，用來定義這個物件內有甚麼，也就是說，用來定義這個物件是要用來幹嘛的。例如一個Pod內有Container，那kind就是Pod，而Container的資訊則寫在spec欄位，代表這個Pod的功能是host一個Container，至於這個Container要做甚麼事，就寫在spec.containers.X 內囉~
今天主要是介紹一下K8s整個集群的架構，先從一個比較High-Level的角度來切入，我想大家可能會比較容易理解。但今天只是個簡單的介紹，若要詳細了解每個組件到底在做甚麼，可以參考其他大神的文章，都寫得很好喔~
另外提一下，其實當我們在使用K8s的時候，不需要特地區分某個功能是由哪個組件implement，就算不知道使用上也不會有影響。但在troubleshooting的時候，如果對這些組件的功能都有了解，會比較容易debug唷~
明天就來實際建置我們的K8s集群吧~
Kubernetes Components
Kubernetes 基礎教學
You can find me on
關於 Container Runtime 的部分，rkt 已經停止開發了
看一下 k8s 官方文件 只列出三個常用的 container runtime
不知道 k8s 跟 CRI 跟 container runtimes 之間的版本怎搭配選擇的?
iThome鐵人賽
看影片追技術